The result is validated in PostgreSQL in https://onecompiler.com/postgresql/44u4qdgpy and result is as expected

sql -> sql programs
was -> were

Thanks for the remind, done.

I think this won't work for DECIMAL values with large precisions, since double has only 53 bits of mantissa, which is insufficient to store large decimal values without a large precision loss. If the decimals are close in values, the error will be very large.

I think using BigDecimal is probably a better approach.

Makes sense. I’ve updated the handling logic to use BigDecimal instead of double.

Can you please add tests for other numeric types, in particular DOUBLE, some large DECIMALS, some of which are very close to each other, and UNSIGNED?

I had added related tests and validate in https://onecompiler.com/oracle/44v8xy4ft
Judging by the results:
-PostgreSQL, percentile_cont returns only double precision (53-bit mantissa, approximately 15–16 decimal digits); converting a 19-digit DECIMAL value to this type results in a loss of precision—for instance, 9999999999999999991 becomes 1e+19.
-Calcite (after modification): Uses BigDecimal throughout; the return type matches the ORDER BY column (i.e., DECIMAL(19,0)), fully preserving the 19-digit precision to yield the exact value 9999999999999999991.0.

The SQL standard may allow percentile_cont to return a double for exact numeric types, and PostgreSQL is one implementation that follows that (I also tested Oracle as well, and it behaves the same way). Of course, having Calcite preserve the input type's precision would be more user-friendly for those using DECIMAL—which is the approach currently adopted.

Few databases support the UNSIGNED type, so I chose DuckDB for testing; the results returned matched the expected test outcomes.（can be validated in https://shell.duckdb.org/）：
using:

  select
    percentile_cont(0.5) within group (order by v) as c,
    percentile_disc(0.5) within group (order by v) as d
  from (values (cast(10 as uinteger)),
               (cast(20 as uinteger))) as t(v);

result is :

┌────────┬────────┐
│   c    │   d    │
│ double │ uint32 │
├────────┼────────┤
│ 15.0   │ 10     │
└────────┴────────┘

You don't need to run tests on duckdb, these tests would produce the same results using integers. The only thing that is different is the overflow behavior.